Modern information technology provides a vast array of software items to meet many different needs. However, after a need is identified, the sheer volume of available technology makes locating suitable items difficult. Systems or the items they provide may duplicate the functionality of other systems or items. Different pieces of software often behave inconsistently. Accessing and using items is difficult because items are often available only through systems that are not compatible with the system on which the items would be used.
Furthermore, accessing items through the Internet, though tremendously useful, is inherently unsafe and unreliable at present. A location that was uninfected yesterday may be virus-ridden or simply unavailable today. It is difficult to ensure that a virus, a snoop, or other undesired software has not been embedded in or substituted for a component. It is also difficult to track use of components for license and accounting purposes, so there is less commercial incentive to make Internet software library servers continually available and secure.
As used herein, "Internet server," "Internet client" and like terms refer to a computer that is identified by an Internet address. Internet addresses are discussed in E. Krol, The Whole Internet: User's Guide and Catalog, second edition, ISBN 1-56592-063-5 ("Internet Guide"), pages 23-34.
One approach to reducing these problems relies on the applet feature of the Java.TM. programming language and environment. (JAVA is a trademark of Sun Microsystems, Inc.) The Java language and environment are described in The Java.TM. Programming Language, by Ken Arnold and James Gosling, ISBN 0-201-63455-4 ("Java Programming Language") and in other commercially available books, CD-ROMs, Web sites and the like. A wide variety of Java software components, Java browser controls, Java automation objects, and related tools are commercially available.
The Java programming language supports miniature application programs called "applets" that are executed while users view World Wide Web pages. Applets are linked or included in Web pages through HTML, much as images and links to other pages are included. When a user selects the highlighted or underlined portion of the Web page that corresponds to the applet, "byte codes" corresponding to the applet are transferred across the Internet to a Java interpreter in the user's Web browser. The Java interpreter "interprets" the applet byte codes by translating them one (or a few) at a time into binary code that can be executed on the user's computer, executing the binary code, translating the next byte code(s), and so on. Thus, a given applet may run on any machine on which a Java interpreter is available, without any need for revision of the applet by a programmer.
To provide security, however, applets labor under a number of restrictions. Applets are forbidden to read from or write to the local user's hard drive. They are not allowed to read system properties, to run programs, to load dynamic link libraries, or to establish network connections with any site except the site from which the original applet was downloaded.
Programmers will immediately appreciate the difficulties raised in trying to write useful programs that cannot freely access the disk, RAM, and other system resources. The problems inherent in restricting network connectivity are somewhat subtler but also severe. As noted, applets can only look at and download from the site where the applet was originally located. This was designed as a security feature in that the Web site the applet came from is deemed secure, while all other sites are presumed to be insecure. But there is nothing inherently secure about a location just because an applet was downloaded from it.
These severe restrictions are enforced at least in part by the Web browser and its interpreter; applets are not designed to run as stand-alone programs. The applet only displays to a local screen area. The Web browser and/or the interpreter filter out any byte codes in the applet that read from the local disk, write to the local disk, or in general, do anything that leaves permanent results in a client computer's storage medium. In some interpreters, the security features can be disabled, but this makes the client system vulnerable to viruses and the other problems noted above.
The byte codes in applets and other Java programs are organized into "classes" which define "methods" (similar to procedures or functions in other programming languages), "objects" (which are instances of classes), and/or "interfaces" (which declare methods but do not implement them). Java classes, methods, objects, and interfaces are familiar to those of skill in the art.
Only locally loaded classes are available to Java clients; a list of the loaded classes is kept in a local hash table by the computer that loaded the classes. Classes that an applet or Java program or its classes refers to are loaded as needed, unless doing so violates one of the Java security restrictions. An applet or a Java class "refers to" a class definition when it contains a class definition, is capable of reading and/or writing a field that is defined by a class definition, and/or is capable of invoking a method that is defined by a class definition. Java applets, Java applications, and Java classes all refer to Java class definitions. These Java concepts are discussed at length in Java Programming Language and.backslash.or other commercially available references.
A given class may be used in many applets or stand-alone Java programs. However, the present Java language and environment provide no well-established way to license and charge for uses of individual classes. For example, if a class were "checked out" of a class library by a user for 16 minutes, ideally 16 minutes of access at a rate suitable for that class would be billed.
Similarly, there is no well-established way to ensure that a user has a valid license for an individual Java class. For example, if a company has a 100-person site license for a given class, a warning or refusal or surcharge would ideally be presented when the 101.sup.st concurrent user from that company requests the class.
A tool that has not previously been used in managing Java classes is known as a "directory services provider." Directory services providers vary but in general they help administer both the location of network resources and the rights of network users to use those resources. One well-known directory services provider includes NetWare Directory Services ("NDS") software commercially available from Novell, Inc. of Orem, Utah (NETWARE DIRECTORY SERVICES and NDS are trademarks of Novell, Inc.).
The directory services provider includes a schema. The schema includes a set of "attribute syntax" definitions, a set of "attribute" definitions, and a set of "database object class" definitions. The NDS software and a default NDS schema are described in Bierer et al., NetWare 4 for Professionals, ISBN 1-56205-217-9 ("NetWare 4"), pages 255-342. The terms "attribute" and "property" are used interchangeably in NetWare 4 and herein, as are the terms "attribute syntax" and "property syntax."
Each attribute syntax in the schema is specified by an attribute syntax name and the kind and/or range of values that can be assigned to attributes of the given attribute syntax type. Attribute syntaxes include, without limitation, Case Exact String (case-sensitive string), Case Ignore List (case-insensitive string), E-Mail Address, Net Address (valid addresses include IPX and AppleTalk), Path, and Stream (to access data not stored directly in NDS database files). Attribute syntaxes correspond roughly to data types such as integer, float, string, file, stream, or Boolean in conventional programming languages.
Each attribute in the schema has certain information associated with it. Each attribute has an attribute name and an attribute syntax type. The attribute name identifies the attribute, while the attribute syntax limits the values that are assumed by the attribute. For instance, the default NDS schema includes an attribute of syntax type integer having the name "supported connections" which specifies the number of concurrent connections a file server allows.
Each attribute may also have associated with it any or all of the following flags: Non-removable, Hidden, Public Read, Read Only, Single-Valued, Sized, and String. The general meanings of these flags are familiar to those of skill in the art. If the Sized flag is set for a given attribute, then upper and lower bounds (possibly including No Limit) are imposed on values currently held by that attribute.
Each database object class in the schema also has certain information associated with it. Each database object class has a class name which identifies it, a set of super classes that identifies the other classes from which this class inherits attributes, and a set of containment classes that identifies the classes permitted to contain instances of this class.
Each database object class also has a container flag and an effective flag. The container flag indicates whether the class is a container class, that is, whether it is capable of containing instances of other database object classes. The effective flag indicates whether instances of the class can be defined. Non-effective database object classes are used only to define attributes that will be inherited by other classes, whereas effective classes are used to define inheritable attributes, to define instances, or to define both.
In addition, each database object class groups together certain attributes. The naming attributes of a database object class are those attributes that can be used to name instances of the class. The mandatory attributes of a database object class are those attributes that must exist in each valid instance of the class and/or become mandatory attributes of classes which inherit from the class. The optional attributes of a database object class are those attributes that may, but need not, exist in each valid instance of the class. Optional attributes of a parent class become optional attributes of a child class which inherits from the parent class, unless the attributes are mandatory in some other parent class from which the child inherits, in which case they are also mandatory in the child.
A database object is an instance of a database object class. Different database objects of the same class have the same mandatory attributes but may have different current values in their corresponding mandatory attributes. Different database objects of the same class may have different optional attributes, and/or different current values in their corresponding optional attributes.
NDS database object classes do not necessarily correspond in a one-to-one manner with Java classes, nor do NDS database objects necessarily correspond one-to-one with Java objects. It is unfortunate but nonetheless true that words such as "class" and "object" are widely used to mean different things even by programmers who are talking about computer programs and the like.
The directory services provider also includes a directory services interface library which provides access to the schema and to a database. The schema is an API-extensible schema in that the attributes and object classes found in the schema can be altered through an Application Programmers' Interface ("API") without direct access to the source code that implements the schema. In some embodiments the directory services interface library includes tables or commands stored in a file which is read by the schema during its initialization and when database objects are created, thereby defining the available attributes and classes.
In addition or as an alternative, the directory services interface library includes a set of routines that are available to other code to access and modify the schema. One implementation of the directory services interface library includes an NWDSxxx( ) library that is commercially available from Novell, Inc. of Orem, Utah. The NWDSxxx( ) library is so named because the names of functions and data types defined in the library typically begin with "NWDS," an acronym for "NetWare Directory Services." It would be a straightforward task for one of skill in the art to access the NWDSxxx( ) library from a Java program or a Web browser.
The directory services database contains database objects that are defined according to the schema and the particulars of the network. These objects typically represent resources of the network. The database is a "hierarchical" database because the objects in the database are connected in a hierarchical tree structure. Objects in the tree that can contain other objects are called "container objects" and must be instances of a container object class.
The database is also a "synchronized-partition" database. The database is typically divided into two or more non-overlapping partitions. To improve the response time to database queries and to provide fault-tolerance, a replica of each partition is physically stored on one or more file servers in the network. The replicas of a given partition are regularly updated by the directory services provider through an automated synchronization process, thereby reducing the differences between replicas caused by activity on the network.
Other network administration tools which the Java environment fails to utilize are NWAdmin and its possible "snap-in" modules. The descriptions of these tools in commonly owned application Ser. No. 08/499,711, filed Jul. 7, 1995 now U.S. Pat. No. 5,692,129, issued on Nov. 25, 1997 are incorporated herein by reference.
Thus, it would be an advancement in the art to provide a novel method for managing Java classes which are distributed in a computer network.
It would be an additional advancement to provide such a method which takes advantage of the security and licensing capabilities of directory services providers.
Such a method for managing software components is disclosed and claimed herein.